前言：改動不大，是不是就不用委派？

「這個任務範圍很小，直接自己做不是比開一個獨立 agent 還快嗎？」

這是個很常見的直覺，而且這個直覺的判斷依據其實錯了。很多人（包含我自己一開始）以為委派的門檻是「這次改動大不大」——改動大才值得委派，小改動自己動手比較快。但實際踩過幾次坑之後才發現，真正決定該不該委派的變數，從來不是改動的大小。

今日目標

• 理解「改動大小」為什麼不是判斷該不該委派的正確依據
• 認識真正的判斷標準：使用者是不是在即時來回討論
• 看清楚「即時討論」跟「可獨立執行」這兩種情境下,委派的成本結構完全不同
• 建立一套實際可以套用的委派判斷習慣

為什麼「改動大小」是個誤導性的判斷依據

昨天講的是「驗證一條記憶還新不新鮮」這件事,其實本身就很適合委派給獨立 agent 去查——這件事聽起來範圍很小（不過是跑幾個指令確認現況），但依然值得委派。這就已經暴露出「改動大小」不是正確判斷依據的第一個線索：一個查證動作規模再小，只要它「不需要每一步都被盯著看」，委派出去讓它自己跑完,回來一次性看結果,反而比自己一步步做更有效率。

真正決定委派划不划算的，是溝通開銷跟任務本身耗時的比例。委派有一個固定成本：交代清楚任務範圍、等待執行、拿回結果、消化結果——這個固定成本不會因為任務「很小」就消失。如果使用者當下正在跟你即時來回討論、每一步都想立刻看到結果、下一步要怎麼走取決於這一步的結果，那麼委派的固定成本（等待、消化）會比自己直接做的成本還高，即使這個任務本身客觀來說可能比昨天那個查證動作更大。

真正的判斷標準：即時討論 vs 可獨立執行

把這個觀察講成一句可以直接套用的規則：委派的判斷標準不是「這次改動大不大」，而是「使用者現在是不是在即時來回討論、每一步都要立刻看到結果」。

適合委派的任務通常有三個共同特徵：範圍明確（不需要中途頻繁確認方向）、不需要每一步都被盯著（可以自己跑完再回報）、產出可以事後審查（就算做錯了，回頭看結果也能判斷哪裡不對，不需要全程盯著過程）。反過來，不適合委派的情境，往往是使用者正在跟你一起釐清問題、下一步要往哪走還沒確定、每個回應都會直接影響接下來要問的問題——這種時候把任務丟給獨立 agent，反而要花更多力氣把「我們剛才討論到哪裡」重新解釋一次給它聽。

用一組對照來看這個差異：

❌ 即時討論中硬要委派：
使用者：「這個判斷邏輯感覺怪怪的，你覺得是哪裡的問題？」
AI：「我開一個獨立 agent 去查一下。」
→ 獨立 agent 需要重新理解「哪裡怪怪的」這個模糊描述，
  查完回報後使用者可能會說「不是這個意思」，
  又要重新委派一次——來回的溝通開銷比自己當場一起釐清還高

✅ 判斷情境選擇直接做：
使用者：「這個判斷邏輯感覺怪怪的，你覺得是哪裡的問題？」
AI：直接在當下對話裡讀程式碼、跟使用者一起釐清，
    邊看邊確認「你是指這裡嗎？」
→ 每一步的方向都靠即時對話校正，不需要事後解讀委派結果

反過來，如果使用者說的是「幫我確認一下這批項目裡有哪些其實已經有真實資料了，我等下要看結論」——這句話本身就劃出了明確範圍、不需要中途確認、產出（一份清單）可以事後直接審查。這種情境丟給獨立 agent 去跑，讓對話回到主線繼續做別的事,才是委派真正該發揮效益的地方。

這跟系列主題句的關係

判斷該不該委派，本質上也是一種「查證範圍」的問題——委派前要先查證清楚「這個任務的邊界夠不夠明確，明確到可以讓另一個沒有當下對話脈絡的 agent 獨立完成」。 如果邊界本身就是模糊的、還在跟使用者一起釐清中，委派出去只是把「範圍不明確」這個根本問題,轉嫁成「獨立 agent 猜錯方向」的額外成本，而不是真的解決了什麼。

今日思考題

回想你上一次猶豫「這個要不要委派給獨立 agent 處理」的時候，你當時考慮的是任務的大小，還是使用者當下是不是在跟你即時討論？如果是前者，這個判斷可能一開始就問錯了問題。

今日重點回顧

• 「改動大小」不是判斷該不該委派的正確依據，判斷標準是溝通開銷跟任務耗時的比例
• 真正的判斷標準：使用者是不是在即時來回討論、每一步都要立刻看到結果
• 適合委派的任務：範圍明確、不需要每步確認、產出可事後審查
• 委派前要先確認任務邊界夠不夠明確——這本身也是一種查證範圍的問題，呼應系列主題句

明日預告

明天把「委派給獨立 agent」這個原則套用到一個更具體的情境：讓 AI 幫忙做 code review。獨立的 review agent 該怎麼設計，才能真的抓到架構風險、避免自己審查自己的盲點。